Long-Term Evolution (LTE—this is evolution of UTRAN UMTS (Universal Mobile Telecommunication System) Terrestrial Radio Access Network) Multimedia Broadcast/Multicast Service MBMS (as defined in 3GPP—3rd Generation Partnership Project) is planned to support Multimedia Broadcast Single-Frequency Network (MBSFN) operation, in which macro diversity gain is accomplished by transmitting exactly the same signals from all base stations (eNB—evolved Node B (LTE base station) belonging to an MBSFN Area.
An MBSFN Area may be defined as a set of cells transmitting synchronised data of the same MBMS service. For multicell reception to work properly in a terminal (UE) receiving the signal from an MBSFN, the same bits should be transmitted from all the eNBs belonging to the MBSFN within a time period defined by a cyclic prefix (CP) of the OFDM (Orthogonal Frequency Division Multiplexing) signal, signal propagation and inter-site distance.
During proper operation the signals from different participating cells combine in the terminal receiver in the same way as if they were multipath components originating from the same transmitter. If different bits are sent from different eNBs, the signals may interfere destructively. An eNB may transmit content from multiple MBSFNs and/or cell-specific content. MBMS can be provided either on a dedicated MBMS frequency layer or a mixed layer, where unicast transmission (including single-cell MBMS content) can be time-multiplexed with MBSFN transmission on the same frequency layer.
In 3GPP TS 22.246, “Multimedia Broadcast/Multicast Service (MBMS) user services; Stage 1(Release 8)”, v. 8.3.0, March 2007 the requirement for channel change of MBMS-based TV service is given as follows:                The MBMS service shall add no more than 1 second when switching between different TV streams to any delay introduced with regards to the coding of the TV stream.        It shall be possible for an operator to configure the MBMS Television service so that the typical switching time, from the end user's perspective, does not exceed 2 seconds.        
The data rate of an encoded video signal may be variable. H.264 (as defined by ITU International Telecommunication Union) is currently the only specified codec for WCDMA (Wideband Code Division Multiple Access) MBMS video streaming (including television) services. Even though content-based differences (amount of motion in video picture) mostly do not produce data rate variations after encoding, due to the somewhat unpredictable need to include “full picture” frames (also known as I-frames) there can be significant variations in the data rate of an encoded video signal. An example of this data rate variation is shown in FIG. 1. Even though the stream was generated using a “Constant Bitrate” encoder setting, the maximum data rate was 403 kbps, while average was 322 kbps.
FIG. 1 shows a graph of data rate on the y axis against 1 second time intervals on the x axis. As can be seen, the data rate for each 1 second interval varies from interval to interval—that is the amount of data transmitted in a 1 second interval varies.
Due to the channel change requirement, the maximum I-frame interval (full picture required to start playback of the video stream) should be about 1 second. In order to ensure transmission of the I-frame within one second, buffering or traffic shaping of data is arranged so that the 1 second averaging period is not exceeded. In order to transmit the data shown in, FIG. 1 the TV service can either be served by a variable bitrate connection, or transmission resources of about 25% above average level can be reserved, resulting in significant wasting of radio resources. As the data rates of different TV channels are normally uncorrelated, multiplexing of multiple MBMS services tends to stabilize the aggregate data rate.
Full E (evolved)-MBMS architecture, as currently discussed in RAN WG3 (Radio Access Network Working Group 3), is shown in FIG. 2. As schematically shown in FIG. 2, there are three domains: the application domain 2, the EPC (Evolved packet core) domain 4 and the E-UTRAN (Evolved UTRAN) domain 6. The application domain comprises a BM-SC 8 Broadcast Multicast Service Centre responsible for the delivery of MBMS services. The BM-SC is a source of MBMS content such as TV transmissions. It can be used with various different radio access technologies, at the same time. The EPC domain comprises a MBMS gateway GW 10. The E-UTRAN domain 6 comprises an IP (Internet Protocol) multicast functionality 12, a coordinating control-plane node MBMS Control Entity (MCE) 14 and a plurality of eNBs 16.
The BM-SC 8 is arranged to communicate with the MBMS GW 10. The MBMS GW 10 is arranged to be connected to the IP Multicast functionality and to the MCE 14. The MCE 14 is connected to at least some eNBs 16 but not necessarily all of the eNBs 16. The MCE 14 will be connected to the eNBs in the defined MBSFN area. The MCE 14 is also arranged to be connected to the IP multicast functionality 12. The IP multicast functionality 12 is connected to the eNBs 16.
The BM-SC 8 provides user-plane broadcast data to the MBMS GW 10 which in turn provides signals to the IP multicast functionality 12. The IP multicast functionality 12 provides signals to the eNBs 16 and the MCE 14. The MCE 14 provides signals to the MBMS gateway 10. The MCE 14 is arranged to have the function of allocation of the radio resources used by all eNBs in the MBSFN area for multi-cell MBMS transmissions using MBSFN operation.
Reference is made to FIG. 3 which shows the so called “Lightweight MBMS deployment”, where the MCE as a separate node is omitted. This is to provide a simplified architecture compared to the arrangement of FIG. 2. As can be seen from a comparison between FIGS. 2 and 3, the architectures look similar apart from the omission of the MCE entity. One of the limitations of a lightweight deployment is that it does not support frequent allocation and re-allocation of radio resources. Therefore variable bitrates are not supported as a centralized function.
With a full E-MBMS architecture, support of bitrate variation for every scheduling period may require very frequent signalling between the MBMS GW 10 and MCE 14. The MBMS GW 10 would need to indicate for every scheduling period the offered amount of data for every MBMS service, and the MCE 14 would need to indicate allocated capacity for each MBMS service.
In order to provide an efficient use of resources, support of variable bitrate per MBMS service may be required. A centralized solution, where a centralized node would monitor the amount of offered traffic for each service, and schedule traffic accordingly, is not compatible with the lightweight deployment and not preferred for the currently agreed 3GPP architecture, which seeks maximum alignment with the distributed architecture used in unicast.
The inventors have appreciated that there is a problem to get statistical multiplexing gain, while supporting guaranteed bitrate per service in a distributed solution, maintaining content synchronization across all eNBs also in case of data loss on the M1-u interface (that is the interface between the IP multicast functionality and the eNBs in the MBSFN area) which needs to be addressed.
In DVB-H (Digital Video Broadcasting-Handheld) this problem has been addressed by multiplexing in a centralized node on a layer denoted as “MPE-FEC”—Multiprotocol Encapsulation—Forward Error Correction. Multiple TV-channels can be summed to one multiplex of MPE-FEC frames, where the aggregate data rate is averaged by the multiplexing. While this centralized solution is straightforward, it may be incompatible with the current E-UTRAN MBMS architecture.